example: https://github.com/apachelogger/snap-appstreamtest In KDE software we often use dbus on applications and 90% of the time do it in fashion that also discretely exposes this information via the desktop file. When a snapcraft `app` has a desktop file (in snap/, or via desktop-file:, or via common-id:) it could check this desktop file for a 'X-DBUS-ServiceName' entry and automatically inject the relevant dbus boilerplate to register the service with the snap app. From the snap-appstreamtest example - snapcraft.yaml has app kbruch and that has common-id org.kde.kbruch.desktop - the appstream data for that common-id define a launchable org.kde.kbruch.desktop - https://github.com/apachelogger/snap-appstreamtest/blob/master/src/usr/share/applications/org.kde.kbruch.desktop - desktop file has `X-DBUS-ServiceName=org.kde.kbruch` - snapcraft could automatically inject a boilerplate slot to enable dbus. slots: dbus-session-org-kde-kbruch: interface: dbus name: org.kde.kbruch # as per the desktop file entry bus: session Currently the dev experience sucks a bit because they'd snap an application (and forget about dbus, because why wouldn't they), upload to store, wait for snap tests to pass, publish, install, and find that the application usually will not work because it attempts to register on dbus and fails to (and usually that is handled as a fatal problem). If snapcraft automatically detected dbus names this would just work out of the box.